Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: Update version for release (pre) #9402

Merged
merged 1 commit into from
May 9, 2024

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented May 9, 2024

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to release-next, this PR will be updated.

⚠️⚠️⚠️⚠️⚠️⚠️

release-next is currently in pre mode so this branch has prereleases rather than normal releases. If you want to exit prereleases, run changeset pre exit on release-next.

⚠️⚠️⚠️⚠️⚠️⚠️

Releases

@remix-run/architect@2.9.2-pre.0

Patch Changes

  • Updated dependencies:
    • @remix-run/node@2.9.2-pre.0

@remix-run/cloudflare@2.9.2-pre.0

Patch Changes

  • Typesafety for single-fetch: defineLoader, defineClientLoader, defineAction, defineClientAction (#9372)

    defineLoader and defineAction are helpers for authoring loaders and actions.
    They are identity functions; they don't modify your loader or action at runtime.
    Rather, they exist solely for typesafety by providing types for args and by ensuring valid return types.

    export let loader = defineLoader(({ request }) => {
      //                                ^? Request
      return { a: 1, b: () => 2 };
      //           ^ type error: `b` is not serializable
    });

    Note that defineLoader and defineAction are not technically necessary for defining loaders and actions if you aren't concerned with typesafety:

    // this totally works! and typechecking is happy too!
    export let loader = () => {
      return { a: 1 };
    };

    This means that you can opt-in to defineLoader incrementally, one loader at a time.

    You can return custom responses via the json/defer utilities, but doing so will revert back to the old JSON-based typesafety mechanism:

    let loader1 = () => {
      return { a: 1, b: new Date() };
    };
    let data1 = useLoaderData<typeof loader1>();
    //  ^? {a: number, b: Date}
    
    let loader2 = () => {
      return json({ a: 1, b: new Date() }); // this opts-out of turbo-stream
    };
    let data2 = useLoaderData<typeof loader2>();
    //  ^? JsonifyObject<{a: number, b: Date}> which is really {a: number, b: string}

    You can also continue to return totally custom responses with Response though this continues to be outside of the typesystem since the built-in Response type is not generic

  • Updated dependencies:

    • @remix-run/server-runtime@2.9.2-pre.0

@remix-run/cloudflare-pages@2.9.2-pre.0

Patch Changes

  • Updated dependencies:
    • @remix-run/cloudflare@2.9.2-pre.0

@remix-run/cloudflare-workers@2.9.2-pre.0

Patch Changes

  • Updated dependencies:
    • @remix-run/cloudflare@2.9.2-pre.0

@remix-run/deno@2.9.2-pre.0

Patch Changes

  • Typesafety for single-fetch: defineLoader, defineClientLoader, defineAction, defineClientAction (#9372)

    defineLoader and defineAction are helpers for authoring loaders and actions.
    They are identity functions; they don't modify your loader or action at runtime.
    Rather, they exist solely for typesafety by providing types for args and by ensuring valid return types.

    export let loader = defineLoader(({ request }) => {
      //                                ^? Request
      return { a: 1, b: () => 2 };
      //           ^ type error: `b` is not serializable
    });

    Note that defineLoader and defineAction are not technically necessary for defining loaders and actions if you aren't concerned with typesafety:

    // this totally works! and typechecking is happy too!
    export let loader = () => {
      return { a: 1 };
    };

    This means that you can opt-in to defineLoader incrementally, one loader at a time.

    You can return custom responses via the json/defer utilities, but doing so will revert back to the old JSON-based typesafety mechanism:

    let loader1 = () => {
      return { a: 1, b: new Date() };
    };
    let data1 = useLoaderData<typeof loader1>();
    //  ^? {a: number, b: Date}
    
    let loader2 = () => {
      return json({ a: 1, b: new Date() }); // this opts-out of turbo-stream
    };
    let data2 = useLoaderData<typeof loader2>();
    //  ^? JsonifyObject<{a: number, b: Date}> which is really {a: number, b: string}

    You can also continue to return totally custom responses with Response though this continues to be outside of the typesystem since the built-in Response type is not generic

  • Updated dependencies:

    • @remix-run/server-runtime@2.9.2-pre.0

@remix-run/dev@2.9.2-pre.0

Patch Changes

  • Fix dest already exists error when running remix vite:build (#9305)
  • Vite: Fix issue resolving critical CSS during development when route files are located outside of the app directory. (#9194)
  • Remove @remix-run/node from Vite plugin's optimizeDeps.include list since it was unnecessary and resulted in Vite warnings when not depending on this package. (#9287)
  • Clean up redundant ?client-route=1 imports in development (#9395)
  • Ensure Babel config files are not referenced when applying the react-refresh Babel transform within the Remix Vite plugin (#9241)
  • Updated dependencies:
    • @remix-run/react@2.9.2-pre.0
    • @remix-run/server-runtime@2.9.2-pre.0
    • @remix-run/node@2.9.2-pre.0
    • @remix-run/serve@2.9.2-pre.0

@remix-run/express@2.9.2-pre.0

Patch Changes

  • Updated dependencies:
    • @remix-run/node@2.9.2-pre.0

@remix-run/node@2.9.2-pre.0

Patch Changes

  • Typesafety for single-fetch: defineLoader, defineClientLoader, defineAction, defineClientAction (#9372)

    defineLoader and defineAction are helpers for authoring loaders and actions.
    They are identity functions; they don't modify your loader or action at runtime.
    Rather, they exist solely for typesafety by providing types for args and by ensuring valid return types.

    export let loader = defineLoader(({ request }) => {
      //                                ^? Request
      return { a: 1, b: () => 2 };
      //           ^ type error: `b` is not serializable
    });

    Note that defineLoader and defineAction are not technically necessary for defining loaders and actions if you aren't concerned with typesafety:

    // this totally works! and typechecking is happy too!
    export let loader = () => {
      return { a: 1 };
    };

    This means that you can opt-in to defineLoader incrementally, one loader at a time.

    You can return custom responses via the json/defer utilities, but doing so will revert back to the old JSON-based typesafety mechanism:

    let loader1 = () => {
      return { a: 1, b: new Date() };
    };
    let data1 = useLoaderData<typeof loader1>();
    //  ^? {a: number, b: Date}
    
    let loader2 = () => {
      return json({ a: 1, b: new Date() }); // this opts-out of turbo-stream
    };
    let data2 = useLoaderData<typeof loader2>();
    //  ^? JsonifyObject<{a: number, b: Date}> which is really {a: number, b: string}

    You can also continue to return totally custom responses with Response though this continues to be outside of the typesystem since the built-in Response type is not generic

  • Updated dependencies:

    • @remix-run/server-runtime@2.9.2-pre.0

@remix-run/react@2.9.2-pre.0

Patch Changes

  • Add undefined to useActionData type override (#9322)

  • Allow a nonce to be set on single fetch stream transfer inline scripts (#9364)

  • Typesafety for single-fetch: defineLoader, defineClientLoader, defineAction, defineClientAction (#9372)

    defineLoader and defineAction are helpers for authoring loaders and actions.
    They are identity functions; they don't modify your loader or action at runtime.
    Rather, they exist solely for typesafety by providing types for args and by ensuring valid return types.

    export let loader = defineLoader(({ request }) => {
      //                                ^? Request
      return { a: 1, b: () => 2 };
      //           ^ type error: `b` is not serializable
    });

    Note that defineLoader and defineAction are not technically necessary for defining loaders and actions if you aren't concerned with typesafety:

    // this totally works! and typechecking is happy too!
    export let loader = () => {
      return { a: 1 };
    };

    This means that you can opt-in to defineLoader incrementally, one loader at a time.

    You can return custom responses via the json/defer utilities, but doing so will revert back to the old JSON-based typesafety mechanism:

    let loader1 = () => {
      return { a: 1, b: new Date() };
    };
    let data1 = useLoaderData<typeof loader1>();
    //  ^? {a: number, b: Date}
    
    let loader2 = () => {
      return json({ a: 1, b: new Date() }); // this opts-out of turbo-stream
    };
    let data2 = useLoaderData<typeof loader2>();
    //  ^? JsonifyObject<{a: number, b: Date}> which is really {a: number, b: string}

    You can also continue to return totally custom responses with Response though this continues to be outside of the typesystem since the built-in Response type is not generic

  • Updated dependencies:

    • @remix-run/server-runtime@2.9.2-pre.0

@remix-run/serve@2.9.2-pre.0

Patch Changes

  • Updated dependencies:
    • @remix-run/node@2.9.2-pre.0
    • @remix-run/express@2.9.2-pre.0

@remix-run/server-runtime@2.9.2-pre.0

Patch Changes

  • Don't log thrown response stubs via handleError in Single Fetch (#9369)

  • Automatically wrap resource route naked object returns in json() for back-compat in v2 (and log deprecation warning) (#9349)

  • Typesafety for single-fetch: defineLoader, defineClientLoader, defineAction, defineClientAction (#9372)

    defineLoader and defineAction are helpers for authoring loaders and actions.
    They are identity functions; they don't modify your loader or action at runtime.
    Rather, they exist solely for typesafety by providing types for args and by ensuring valid return types.

    export let loader = defineLoader(({ request }) => {
      //                                ^? Request
      return { a: 1, b: () => 2 };
      //           ^ type error: `b` is not serializable
    });

    Note that defineLoader and defineAction are not technically necessary for defining loaders and actions if you aren't concerned with typesafety:

    // this totally works! and typechecking is happy too!
    export let loader = () => {
      return { a: 1 };
    };

    This means that you can opt-in to defineLoader incrementally, one loader at a time.

    You can return custom responses via the json/defer utilities, but doing so will revert back to the old JSON-based typesafety mechanism:

    let loader1 = () => {
      return { a: 1, b: new Date() };
    };
    let data1 = useLoaderData<typeof loader1>();
    //  ^? {a: number, b: Date}
    
    let loader2 = () => {
      return json({ a: 1, b: new Date() }); // this opts-out of turbo-stream
    };
    let data2 = useLoaderData<typeof loader2>();
    //  ^? JsonifyObject<{a: number, b: Date}> which is really {a: number, b: string}

    You can also continue to return totally custom responses with Response though this continues to be outside of the typesystem since the built-in Response type is not generic

  • Pass response stub to resource route handlerså when single fetch is enabled (#9349)

@remix-run/testing@2.9.2-pre.0

Patch Changes

  • Updated dependencies:
    • @remix-run/react@2.9.2-pre.0
    • @remix-run/node@2.9.2-pre.0

create-remix@2.9.2-pre.0

remix@2.9.2-pre.0

remix

See the CHANGELOG.md in individual Remix packages for all changes.

@remix-run/css-bundle@2.9.2-pre.0

@remix-run/eslint-config@2.9.2-pre.0

@brophdawg11 brophdawg11 merged commit 62db2d7 into release-next May 9, 2024
1 check passed
@brophdawg11 brophdawg11 deleted the changeset-release/release-next branch May 9, 2024 18:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant